1. Field of the Invention
This invention generally relates to database systems for computers and, more particularly, to an apparatus and methods for loading stored procedures in a database corresponding to object-oriented data dependencies.
2. Description of the Related Art
Conventional object-database mapping tools receive class definitions from an object-oriented application and automatically generate code, typically stored in a database schema, to create tables and other structures for the database. The tables and structures in the database are used to hold data corresponding to objects in an object-oriented application. Differences in object-oriented applications and databases make it difficult to develop these object-database mapping tools.
In an object-oriented application the skeleton of an object is a class. The class may have a number of fields used to store values or parameters typically used by object instances of the class. The class may also include specific methods which define how objects instantiated from each class will interact with each other and hold certain information in each of the corresponding fields. A hierarchical class structure provides an organized framework for creating objects and their relationships.
The database typically organizes data using one or more tables having multiple rows and columns. A data relationship is defined by the manner in which data is stored in the various rows and columns of the tables. A single table or multiple tables can be used to hold every row or record of data. A primary key includes one or more columns in a table that uniquely define each row of data. If multiple tables are used to store a data, a foreign key associates rows of data in one table with another table. Stored procedures are used in databases to manipulate tables of data. These stored procedures are small compiled programs written in a database language such as Structured Query Language (SQL) and stored in the database.
Database developers create stored procedures to save time performing routine database functions. Stored procedures can be combined to perform complex operations by having one stored procedure call another stored procedure. Generally, database developers understand the data dependencies related to the stored procedures because they are developing the customized code. Specifically, if one stored procedure calls a second stored procedure, the second stored procedures must be declared or defined before the first stored procedure can call or invoke it. Thus, the developer makes sure all stored procedures are defined in the stored procedure area of a database before they are called by another stored procedure. A failure to do this results either in a compilation error or run-time error because the database can not resolve references and the calling stored procedure can not locate the called stored procedure.
Loading stored procedures in proper order is more difficult when they are used to manipulate data in a database corresponding to objects in an object-oriented application. The loading order depends on the relationships between objects, hierarchical class structure, and the order stored procedures are called. For example, deleting a subclass object requires deleting corresponding entries for the superclass object stored in the database. Assume a disk drive object is a subclass of a part object superclass. To delete a disk drive object, a corresponding relationship must be deleted from the part object superclass. In the database, a stored procedure deletes the disk drive entry in a table and calls another stored procedure to delete the corresponding relationship in the part table of the database. The latter stored procedure must be loaded in the database before the former stored procedure can call and reference it.
To avoid the complexities associated with using stored procedures, conventional object-database mapping tools use Structured Query Language (SQL) and do not even attempt to tackle the complexities of using stored procedures. Unlike SQL, stored procedures are generally not portable and must be developed, compiled, and loaded for each different type of database. These conventional object-database mapping tools prefer to support SQL over stored procedures even though stored procedures are faster and have more powerful programming constructions.
As a result, the user must develop, compile, and load stored procedures manually into the database. The object-oriented user or programmer must have a detailed understanding of both object-oriented and database concepts to develop and use stored procedures. The user must also be familiar with techniques for compiling and loading these stored procedures for each different database. Overall, this deters users from gaining the higher performance offered by using stored procedures on the databases.
Based on the above limitations found in conventional database and object-oriented systems, it is desirable to have an object-database mapping tool load the stored procedures in a database corresponding to object-oriented data dependencies.